1. Technical Field of the Invention
The present invention relates to the architecture of a 3-layer Provider Provide VPN (PP VPN) and constructing method thereof.
2. Background
There are different implementations of traditional PP VPN architecture in actual applications, such as BGP/MPLS VPN, VR VPN, and MPLS 12 VPN, etc. As for BGP/MPLS VPN (Multi Protocol Label Switch based on Switch Border Gateway Protocol), the PP VPN is a network that delivers IP VPN service in public networks with MPLS technology and BGP. The BGP/MPLS VPN architecture mainly comprises a backbone network composed of P devices and PE devices provided by ISP as well as subscribers' VPN that comprises a plurality of sites and CE devices.
In said devices, P (Provider Router) devices are mainly responsible for forwarding MPLS. PE (Provider Edge Router) devices are the main body to realize MPLS/BGP VPN service, and they maintain independent lists of sites in subscribers' VPNs, and detect VPN topologies and learn internal VPN routes through BGP. CE (Custom Edge Router) devices are common routers, and they connect sites in subscribers' VPNs to PEs, without supporting any MPLS or VPN signaling or protocol.
In the BGP/MPLS VPN architecture, PE devices may be the bottleneck in large-scale deployments because they have to converge routes from a plurality of VPNs (especially in cases that capacity of PE devices is small). Furthermore, most traditional MPLS VPN models are planar ones, wherever a PE device resides in the network, its performance should be the same as others. In such an environment, more routes have to be maintained as PE expands towards edge because routers converge layer by layer. For a 3-layer model typical network employing a core-convergence-access architecture, the performance of devices degrades as the network expands, which brings difficulty to the expansion of network towards the edge. To solve said problem, a Multi-VRF (VPN routing/forwarding instance) scheme is proposed to enhance the capacity of CE devices to deliver VRF functionality. Such devices are called VCE devices. In networking, a plurality of VCE devices and PE devices are combined to form a distributed PE. Seen from FIG. 1, multiple VRFs are configured in VCE, and the VRFs correspond to multiple VPN sites. On each VRF there are some downward interfaces to connect to VCE devices and an upward interface to connect to PE devices. On PE devices, the same VRFs are configured correspondingly, and each VRF has one or more interfaces, which connect with VCE devices. Thus, a Multi-VRF CE device simulates multiple CE devices actually, each virtual CE is isolated from each other to access multiple VPN subscribers, but the PE devices don't “know” whether they are connected to multi CE devices or a VCE device. Therefore, any expansion is unnecessary. Though the scheme solves the problem of expandability of PE devices to some extent, the disadvantage is also obvious, i.e.
a large amount of interfaces, sub-interfaces are needed between PE and VCE devices, which consume limited interfaces and IP addresses resource;
multiple VRFs have to be configured on PE and CE devices, which is a heavy-labor and repetitive work;
if a dynamic route protocol is used in exchange of routes between PE and VCE devices, PEs and VCEs need to run multiple instances; if static routes are used, the configuration is a heavy-labor work;
if tunnel interfaces are used to connect PEs with VCEs instead of direct connection, each VRF will need a tunnel, resulting in heavy consumption of resource;
if different VCEs are connected with each other to deliver VPN messages to reduce the burden on PE devices, each VRF needs an interface/sub-interface.